This invention relates to the field of logic simulation of electronic circuits. More specifically, this invention relates to methods and apparatus for efficiently generating test input for a logic simulator.
Gordon Moore, the cofounder of Intel Corporation, made an observation and diction that semiconductor performance would double every 18 months, with the price of the new product remaining constant with the old. This observation is now referred to as Moore""s Law, and has remained relatively accurate since the early 1970s. Moore""s Law illustrates the rapid advancement that has and is taking place in the electronics industry. Because of this rapid advancement, the market window for many electronic products is relatively short, with faster and more powerful devices being continuously introduced. Accordingly, there is often great pressure to reduce the development time for many products. To significantly reduce the development time for most electronic devices, the design time must be reduced, as the design typically consumes a majority of the development cycle.
FIG. 1 shows a typical prior art design process for an ASIC (Application Specific Integrated Circuit) device. ASIC devices are commonly used to implement large and/or high performance circuit designs. In a first step, a hardware architect typically determines the requirements for the circuit design and formulates an underlying framework of the function and projected performance characteristics of the circuit design. The architect documents these ideas in a functional specification. This is shown at step 12 of FIG. 1.
The design is then typically partitioned into a number of blocks and given to one or more logic designers for implementation. The logic designers create a detailed logic design using the functional specification as a guide. Rather than creating schematics, many logic designers express the design in a behavioral language such as VHDL (VHSIC Hardware Description Language), as shown at step 14. Many logic simulation tools can directly accept behavioral language descriptions as input. This not only improves efficiency in developing complex circuit designs, but also allows various sections of the circuit design to be functionally verified before the entire design is complete.
As shown at step 16, the design is typically logically simulated to verify the functionality thereof To logically simulate the design, the circuit designer typically provides one or more test input files. The test input files may include a number of test conditions often expressed as test vectors. Each of the test vectors may include a value for selected inputs of the circuit design along with an expected circuit response. The logic simulator reads the test input files, simulates the behavior of the circuit design using the test input, and provides a simulated circuit response. The simulated circuit response is then compared to the expected circuit response to determine if the circuit design provides the expected behavior.
To increase the speed of the logic simulator, a test driver may be provided. A test driver typically includes a memory structure or the like that is expressed in a behavioral language description, and is logically connected to the inputs of the circuit design. Prior to simulation, the memory structure of the test driver is loaded with data to control the inputs of the circuit design during logic simulation. For example, data may be loaded into a RAM structure within the test driver, and during logic simulation, the address to the RAM structure may be incremented to provide each of the test vectors to the inputs of the circuit design. The test driver, thus is simulated along with the circuit design. The use of a test driver may increase the speed of the logic simulation by allowing the simulation kernel of the logic simulation tool to run continuously for a longer period of time.
When a test driver is not used, the simulation kernel typically must be interrupted whenever new test vectors are applied. That is, without a test driver, each test vector must typically be applied via a simulation control program. Control must typically be passed between the simulation kernel and the simulation control program for each test vector to be applied. Because the simulation kernel must be continuously interrupted, the efficiency of the logic simulator is often reduced.
After logic simulation is complete, the design is typically passed to one or more physical designers, as shown at step 18. The physical designers place the various cells that represent the basic logic building blocks of the circuit design, and interconnect the cells using a routing tool. Timing information may be extracted and analyzed by both the physical and logical designers. Some timing problems can be fixed by the physical designer by adjusting the drive strengths of various components or placing cells in a different arrangement relative to each other. As shown at step 22, other timing problems can only be resolved by modifying the logic itself. If a problem is resolved by modifying the logic, the modified design must typically be reverified by re-executing logic simulation step 16 and then the physical design step 18.
As shown at step 24, after all the logical and physical changes are made, and the design meets the stated requirements, the design is released for fabrication. For a typical ASIC device, fabrication can take several months. Once completed, the device is returned and tested, as shown at step 26. If the device does not meet the stated requirements, a design modification may be required as shown at step 22, forcing another design iteration of the logic simulation step 16, the physical design step 18, and the fabrication step 24. The device is again tested to determine if the design meets all of the stated requirements. If the device meets all of the stated requirements, the device is released, as shown at step 30.
In most design processes, it is important to reduce the number of design iterations during the development cycle. Having more than one design iteration can substantially reduce the efficiency of the design process. One way of reducing the number of design iterations is to increase the fault coverage of the logic simulations. Increasing the fault coverage can increase the probability that the design errors will be detected before the design is fabricated. However, increasing the fault coverage increases the time required to generate and simulate the increased number of test cases. Thus, there is often a trade-off between the fault coverage and design cycle time.
FIG. 2 illustrates a prior art logic simulation process. At step 42, the architect and test designer discuss the logic implementation and define a series of test cases that address the various functional sections and possible interactions of the design. In many designs, such as a MSU (Main Storage Unit) design with multiple parallel ports and crossbar switches (see below), there are many possible functional operations and interactions that should be tested. Thus, a large number of test cases are often required to achieve a high level of fault coverage.
For some of the test cases, the test designer can easily define the relevant test parameters. However, for many test cases, such as those that test parallel operating hardware, the test designer must use a certain level of parallel thinking and thus are much more difficult. A test case that simulates the interaction of two parallel operating ports of a circuit design, where the operation of one port must be choreographed with the operation of another port, is an example of a more complex test case. Defining such a test can require a significant amount of parallel thinking, and thus can be relatively difficult and time consuming.
Once the test cases are defined, the test designer typically codes the test cases into a format that can be used to produce an input for the logic simulator. The test designers may, for example, code the test cases into a format that can be readily read by a logic simulator to control the logic simulation. This format may include, for example, a force command, followed by a run command, followed by a force command, etc. This format is particularly suitable when a test driver is not used to control the inputs of the circuit design.
When a test driver is used, however, the test cases may be coded into a standard programming language like xe2x80x9cCxe2x80x9d, as shown at step 44. When executed, the xe2x80x9cCxe2x80x9d programs may generate a series of data files that can be loaded into memory structures within the test driver, as shown at step 46. The xe2x80x9cCxe2x80x9d programs may also generate corresponding initialization files that can be loaded into the device under test (MSU RAMS). During simulation, a series of load commands may be executed by the simulation control program. These load commands may load the data and initialization files into the array structures that represent the simulation models of the appropriate memory structures (e.g. RAMs). Clocks are then issued (simulation starts) and the test is performed as shown at 48.
At the end of the logic simulation, the results are checked to see if the test passed or failed, as shown at step 50. If the test failed, the results are analyzed to determine whether there was a test problem or an actual logic design problem, as shown at step 52. If a test problem is detected, the test is modified and re-executed as shown at step 56. If a logic problem exists, the logic design must be modified, as shown at step 54, and the logic simulations are re-executed to validate the change. When all of the defined test cases pass, as shown at step 58, the logic simulation process is complete.
One limitation of the above-described logic simulation process is that the process of defining and mapping the parallel algorithms into a serial type format such as the xe2x80x9cCxe2x80x9d programming language can be difficult and time consuming. The serial constructs of a standard programming language typically do not readily lend themselves to the parallel nature of many test cases. Thus, it is often difficult to quickly identify which test conditions associated with one circuit section correspond to the test conditions associated with another circuit section. Under many circumstances, the test designer must scroll up through the serial program code and manually identify which values are associated with one another.
As can readily be seen, considerable effort may be required to ensure that the serial implementation, such as the serial constructs of the xe2x80x9cCxe2x80x9d programming language, actually implement the desired parallel test case. In addition, the rigid syntax requirements of many standard programming languages can make it difficult to efficiently code the desired test cases.
The above limitations are magnified because the test designer must typically define and map a large number of test cases to achieve an adequate fault coverage for the logic simulation process. Because of the difficulty in defining and mapping the test cases, as described above, and because a large number of test cases are typically required, the logic simulation process can be the longest and most labor intensive part of the design process. Therefore, even a small increase in the efficiency of the logic simulation process, and in particular the test case definition and mapping process, may significantly improve the efficiency of the overall design process.
The present invention overcomes many of the disadvantages of the prior art by providing an improved method and apparatus for generating test input for a logic simulator. Generally, the present invention provides a template that allows a test designer to more efficiently enter the desired test conditions. The template is preferably arranged to facilitate the definition of test cases, and in particular, parallel type test cases. In an illustrative embodiment, one region of the template is dedicated to one section of the circuit design, and another region is dedicated to another section of the circuit design. When the regions are positioned side-by-side, for example, the test designer can easily identify the test conditions that are applied to the various circuit sections, including the relationships therebetween. Once the test conditions are entered, the template is processed and the desired test input is automatically generated.
In accordance with one illustrative embodiment of the present invention, the template is logically divided into a number of regions, wherein each of the regions corresponds to a different section of the circuit design. The circuit designer enters a number of test conditions into the template by providing a first portion of a selected test condition in a first one of the regions and a second portion of the selected test conditions in a second one of the regions. When the first and second regions are placed side-by-side, for example, the user can easily see which test conditions are applied to the various circuit sections and the relationship therebetween.
Once the desired test conditions are entered into the template, a processor or the like processes the template and provides a test input for the logic simulator. The processor may, for example, read the test conditions from the template and automatically code the test conditions into a format that can be readily read by a logic simulator for controlling the logic simulation. One such format may include, for example, a force command, followed by a run command, followed by a force command, etc. This embodiment may be particularly suitable when a test driver is not used to drive the inputs of the circuit design.
When a test driver is used, the processor may read the test conditions from the template and automatically codes the test conditions into a standard programming language like xe2x80x9cCxe2x80x9d. When executed, the xe2x80x9cCxe2x80x9d program may generate a series of data files that are capable of being loaded into the test driver. The xe2x80x9cCxe2x80x9d program may also generate a set of corresponding initialization files that may be loaded into the device-under-test (MSU RAMs), as more fully described below.
An illustrative circuit design may include, for example, a first parallel port and a second parallel port. The test conditions associated with the first parallel port may be provided in the first region of the template. The test conditions associated with the second parallel port may be provided in the second region of the template. Preferably, the template includes a number of columns and a number of rows, wherein the first region and the second region form at least two of the columns, and each test condition (test vector) forms one or more of the rows. In this arrangement, the relationship between the test conditions for each of the circuit sections can be easily visualized by looking at the values in each of the columns within a single or set of rows. Thus, when one of the circuit sections operates in parallel with another circuit section for a particular test case, the circuit designer can easily visualize the parallel nature of the test case.
Some regions of the template may be dedicated to receiving a number of initialization states for selected circuitry including the circuit design. The circuit design may have to be properly initialized before performing some test cases. Other regions of the template may be dedicated to receiving a number of names with corresponding values. The names may be used as aliases or the like to shorten the descriptions of selected test conditions. For example, a test condition that requires a data value of xe2x80x9c001001000110011001101xe2x80x9d may include an alias or the like that corresponds to the data value, for example DO. Accordingly, the length and apparent complexity of the test condition can be substantially reduced, and the readability of the test condition can be substantially increased.
Preferably, the template is provided via a spreadsheet application program, with various predefined regions corresponding to selected portions of the circuit design. An advantage of using a spreadsheet application program is that the editing functions provided thereby can be used to help input the test conditions into the template.